Sam Hartman: Making our Community Safe: the FSF and rms
I felt disgust and horror when I learned yesterday that rms had returned to the FSF board. When rms resigned back in September of 2019, I was Debian Project Leader. At that time, I felt two things. First, I was happy that the community was finally taking a stand in favor of inclusion, respect, and creating a safe, welcoming place to do our work. It was long past time for rms to move on. But I also felt thankful that rms was not my problem to solve. In significant part because of rms, I had never personally been that involved in the FSF. I considered drafting a statement as Debian Project Leader. I could have talked about how through our Diversity Statement and Code of Conduct we had taken a stand in favor of inclusion and respect. I could have talked about how rms's actions displayed a lack of understanding and empathy and how this created a community that was neither welcoming nor respectful. I didn't. I guess I didn't want to deal with confirming I had sufficient support in the project. I wanted to focus on internal goals, and I was healing and learning from some mistakes I made earlier in the year. It looked like other people were saying what needed to be said and my voice was not required. Silence was a mistake.
It's a mistake I've been making all throughout my interactions with rms. Enough is enough. It's long past time I added my voice to those who cry for accountability and who will not sit aside while rms's disrespect and harm is tolerated.
The first time I was silent about rms was around 15 years ago. I was at a science fiction convention in a crowded party. I didn't know anyone, other than the host of the party. I was out of my depth. I heard his voice---I recognized it from the Share the Software Song. He was hitting on some girl, talking about how he invented Emacs. As best I could tell, she didn't even know what Emacs was. Back then, I wondered what she saw in the interaction; why she stuck around even though she didn't know what he was talking about. I sure didn't want to be around; the interaction between the two of them was making me uncomfortable. Besides, the wings on her costume kept hitting me in the face. So I left as fast as I could.
I've learned a lot about creating safe spaces and avoiding sexual harassment since then. Thinking back, she was probably hitting me because she was trying to back away and getting crowded. If this happened today, I think I would do a better job of owning my responsibility for helping keep the space around me safe. I've learned better techniques for checking in to make sure people around me are comfortable.
I didn't come to silence alone: I had been educated into the culture of avoiding rms and not calling him out. There was a running game in the group of computer security professionals I learned from. The goal was to see how much you could contribute to free software and computer security without being recognized by or interacting with rms. And so, indoctrinated into a culture of silence about the harm that rms caused, I took my first step.
Things weren't much better when I attended Libreplanet 2019 just before taking office as Debian Project Leader. I had stayed away from the conference in large part because of rms. But there were Debian people there, and I was missing community interaction. Unfortunately, I saw that even after the problems of 2018, rms was still treating himself as above community standards. He interrupted speakers, objecting to how they phrased the problem they were considering. After a speech on codes of conduct in the free software community, he cornered the talk organizer to "ask her opinion" about the GNU project's lack of code on conduct. He wasn't asking for an opinion. He was justifying himself; there wasn't much listening in the conversation I heard. Aspects of that conversation crossed professional boundaries for what should be said. The talk organizer was okay--we talked about it after--but if we did a better job of policing our community, that wouldn't even be a question. I think the most telling sign was a discussion with an FSF board member. We were having a great conversation, but he had to interrupt it. He was on rms duty (my words) at the next session. The board had decided it was necessary to have members there so that the staff would not be put in awkward positions by their president. If someone needed to call rms out, it could be a board member rather than the staff members of the conduct team.
And yet again, I held my silence. It's so easy to keep silent. It's not that I never speak up. There are communities where I have called people out. But it's hard to paint that target on yourself. It's hard to engage and to stand strong for a community's standards when you aren't the target. It's hard to approach these problems while maintaining empathy for everyone involved. Some people give into the rage; I don't have that option if I want to be the person I've chosen to be. And so, when I do speak up, the emotional cost is high.
Yet, it's long past time I raised my voice on this issue. Rms has demonstrated that he cannot hold to standards of respect for others, respect for their boundaries, or standards of community safety. We need those standards to be a welcoming community.
If the people who came before me--those who taught me the game of avoiding rms--had spoken up, the community could have healed before I even came on the scene. If I and others had stood up fifteen years ago, we'd have another couple generations who were more used to respect, inclusion, welcoming and safety. The FSF board could have done their job back in 2018. And perhaps if more of us had spoken out in 2019, the FSF board would have found the strength to stand strong and not accept rms's return.
And so, finally, I raise my voice. I signed the open letter calling for the resignation of rms and the entire FSF board. Perhaps if we all get used to raising our voice, it will be easier. Perhaps if we stand together, taking the path of community rather than the path of silence, we'll have the support we need to create communities inclusive enough to welcome everyone who can contribute. For me, I'm done being silent.
There's one criticism of the open letter I'd like to respond to. I've heard concerns about asking for the resignation of the entire FSF board under the understanding that some board members voted against rms's return. It should be obvious why those who voted for rms's return need to resign. But resignation does not always mean you did something wrong. If you find yourself in a leadership role in an organization that takes decisions in significant conflict with your standards of ethics, resignation is also the right path. Staying on the board even if you voted against rms's return means that you consider voting for rms to be a reasonable thing to do. It means that even if you disagreed with it, you can still be part of an organization that takes the path of welcoming rms. At this point, I cannot do that, nor can I support leaders in the FSF who do.
It's a mistake I've been making all throughout my interactions with rms. Enough is enough. It's long past time I added my voice to those who cry for accountability and who will not sit aside while rms's disrespect and harm is tolerated.
The first time I was silent about rms was around 15 years ago. I was at a science fiction convention in a crowded party. I didn't know anyone, other than the host of the party. I was out of my depth. I heard his voice---I recognized it from the Share the Software Song. He was hitting on some girl, talking about how he invented Emacs. As best I could tell, she didn't even know what Emacs was. Back then, I wondered what she saw in the interaction; why she stuck around even though she didn't know what he was talking about. I sure didn't want to be around; the interaction between the two of them was making me uncomfortable. Besides, the wings on her costume kept hitting me in the face. So I left as fast as I could.
I've learned a lot about creating safe spaces and avoiding sexual harassment since then. Thinking back, she was probably hitting me because she was trying to back away and getting crowded. If this happened today, I think I would do a better job of owning my responsibility for helping keep the space around me safe. I've learned better techniques for checking in to make sure people around me are comfortable.
I didn't come to silence alone: I had been educated into the culture of avoiding rms and not calling him out. There was a running game in the group of computer security professionals I learned from. The goal was to see how much you could contribute to free software and computer security without being recognized by or interacting with rms. And so, indoctrinated into a culture of silence about the harm that rms caused, I took my first step.
Things weren't much better when I attended Libreplanet 2019 just before taking office as Debian Project Leader. I had stayed away from the conference in large part because of rms. But there were Debian people there, and I was missing community interaction. Unfortunately, I saw that even after the problems of 2018, rms was still treating himself as above community standards. He interrupted speakers, objecting to how they phrased the problem they were considering. After a speech on codes of conduct in the free software community, he cornered the talk organizer to "ask her opinion" about the GNU project's lack of code on conduct. He wasn't asking for an opinion. He was justifying himself; there wasn't much listening in the conversation I heard. Aspects of that conversation crossed professional boundaries for what should be said. The talk organizer was okay--we talked about it after--but if we did a better job of policing our community, that wouldn't even be a question. I think the most telling sign was a discussion with an FSF board member. We were having a great conversation, but he had to interrupt it. He was on rms duty (my words) at the next session. The board had decided it was necessary to have members there so that the staff would not be put in awkward positions by their president. If someone needed to call rms out, it could be a board member rather than the staff members of the conduct team.
And yet again, I held my silence. It's so easy to keep silent. It's not that I never speak up. There are communities where I have called people out. But it's hard to paint that target on yourself. It's hard to engage and to stand strong for a community's standards when you aren't the target. It's hard to approach these problems while maintaining empathy for everyone involved. Some people give into the rage; I don't have that option if I want to be the person I've chosen to be. And so, when I do speak up, the emotional cost is high.
Yet, it's long past time I raised my voice on this issue. Rms has demonstrated that he cannot hold to standards of respect for others, respect for their boundaries, or standards of community safety. We need those standards to be a welcoming community.
If the people who came before me--those who taught me the game of avoiding rms--had spoken up, the community could have healed before I even came on the scene. If I and others had stood up fifteen years ago, we'd have another couple generations who were more used to respect, inclusion, welcoming and safety. The FSF board could have done their job back in 2018. And perhaps if more of us had spoken out in 2019, the FSF board would have found the strength to stand strong and not accept rms's return.
And so, finally, I raise my voice. I signed the open letter calling for the resignation of rms and the entire FSF board. Perhaps if we all get used to raising our voice, it will be easier. Perhaps if we stand together, taking the path of community rather than the path of silence, we'll have the support we need to create communities inclusive enough to welcome everyone who can contribute. For me, I'm done being silent.
There's one criticism of the open letter I'd like to respond to. I've heard concerns about asking for the resignation of the entire FSF board under the understanding that some board members voted against rms's return. It should be obvious why those who voted for rms's return need to resign. But resignation does not always mean you did something wrong. If you find yourself in a leadership role in an organization that takes decisions in significant conflict with your standards of ethics, resignation is also the right path. Staying on the board even if you voted against rms's return means that you consider voting for rms to be a reasonable thing to do. It means that even if you disagreed with it, you can still be part of an organization that takes the path of welcoming rms. At this point, I cannot do that, nor can I support leaders in the FSF who do.
While struggling with Pfizer second dose side effects yesterday, with little
ability to do anything serious so surreal to have a fever yet also
certainty you re not actually ill[1] I thought I d try building the branch
of Emacs with native Wayland support, and try starting up Sway instead of i3.
I recently upgraded my laptop to Debian bullseye, as I usually do at this
stage of our pre-release freeze, and was wondering whether bullseye would be
the release which would enable me to switch to Wayland.
Why might I want to do this? I don t care about screen tearing and don t have
any fancy monitors with absurd numbers of pixels. Previously, I had been
hoping to cling on to my X11 setup for as long as possible, and switch to
Wayland only once things I want to use started working worse on X11, because
all the developers of those things have stopped using X11. But then after
upgrading to bullseye, I found I had to forward-port an old patch to
xfce4-session to prevent it from resetting SSH_AUTH_SOCK to the wrong value,
and I thought to myself, maybe I could cut out some of the layers here, and
maybe it ll be a bit less annoying. I have a pile of little scripts trying to
glue together xfce4 and i3 to get all the functionality I need, but since
there have been people who use their computers for similar purposes to me
trying to make Sway useful for quite some time now, maybe there are more
integrated solutions available.
I have also been getting tired of things which have only ever half-worked
under X, like toggling autolock off when there isn t fullscreen video playing
(when I m video conferencing on another device, I often want to prevent my
laptop s screen from locking, and it works most of the time, but sometimes
still locks, sigh). I have a normalise desktop keybinding which tries to
fix recurrent issues by doing things like restarting ibus, and it would be
nice to drop something so hackish.
And indeed, a lot of basic things do work way better under Sway. swayidle is
clean and sane, and I was easily able to add a keybinding which inhibits
locking the screen when a certain window is visible. I could bind brightness
up/down keys without having to invoke xfce4-power-manager never managed
that before and, excitingly, I could have those keys bound such that they
still work when the screen is locked. I still need two old scripts which
interact with the i3/sway IPC, but those two are reasonable ways to extend
functionality, rather than bad hacks.
The main thing that I could not figure out is IME various people claim
online to have got typing their Asian languages working natively under Sway,
not just into Xwayland windows, but I couldn t, and there is no standard way
to do it yet, it would seem. Also, it seems Qt in Debian doesn t support
Wayland natively, so far as I could tell. And there isn t really a drop-in
replacement for dmenu yet, so you have to run that under Xwayland. A lot of
this is probably going to be fixed during 2021, but the thing is, I ll be on
Debian bullseye, so how it works now is probably as good as it is going to get
for the next two years or so.
So, wanting to get back to doing something more useful today, I reluctantly
booted back into X11. I m really looking forward to switching to Sway, and
getting rid of some of my hacks, but I think I am probably going to have to
wait for Debian bookworm unless I completely run out of patience with the
various X11 annoyances described above, and start furiously backporting
things.
Update, later that afternoon Newer versions of fcitx5 packages hit Debian
testing within the past few days, it turns out, and the IME problem is solved!
So looks like I am slowly going to be able to migrate to Sway during the
Debian bullseye lifecycle after all. How nice. Many thanks to various
upstreams and those who have been working on these packages in Debian.
[1] Okay, I suppose I could have caught the disease a few days ago and it
became symptomatic at the same time I was experiencing the side effects.
I have written my first Rust crate: 
This is a page from the wonderful 
There are ton of articles out there to configure mutt and all related
things to it. But I find certain configs very hard to get. So I will
write down those.
The KDE Bugzilla handles a lot of projects and they often match with the repo name, but not always.
For instance we have ancient products and components at Bugzilla, as projects have a lifecycle from playground into Release Service, or Frameworks, sometimes with a change of name.
So you may end up searching Bugzilla quite awhile for the correct product and component to be able to confirm or create bug reports against an application.
Let's have a look at 
My inverter has unfortunately died, and I wanted to replace it with the
same model. Ideally before I lose the contents of the fridge. It's a 24v
inverter, which is not at all as easy to find a replacement for as a 12v
inverter would be.
Somehow Walmart was the only retailer that
Joys of sshfs slave mode.
When I want to have parts of my source tree on remote, I use sshfs slave mode, combined with emacs tramp things look very much integrated.
sshfs interface only has obnoxious -o slave option which makes it talk to stdin/stdout, which needs to be connected to sftp-server from the local host. Using dpipe from vde2 seems to be a popular method to run the tool.
Something like:
dpipe /usr/lib/openssh/sftp-server = ssh hostname sshfs :/directory/to/be/shared ~/mnt/src -o slave
I wish I can limit the visibility from sftp-server but maybe that's okay.
